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epartment  of  betense  acquisition  prac¬ 
tices  are  conceptually  structured  to  de¬ 
crease  overhead  costs  while  continuing  to 
improve  cap^il^ies  and  interoperability. 
These  practijcey  mandate  build  versus  buy 
solutions, ^itl/more  emphasis  on  buying 
pre-bui|t:^^ications.  Buying  commercial 
lelf  software— COTS— can  be 
7  efficient  and  effective  solution,  if 
the  context  of  the  life  cycle  is  considered 
in  all  customization  decisions.  If  we  are  to 
achieve  the  expected  gains  from  purchas¬ 
ing  software  versus  building  it  ourselves, 
then  for  the  entire  life  cycle  of  the  product, 
we  cannot  allow  any  modifications.  That  is 
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easily  obtained  in  many  small  systems  with  a  little  disci¬ 
pline;  however,  large  enterprise  resource  planning  (ERP)  so¬ 
lutions  will  encounter  problems  if  not  approached  correctly 
from  its  initial  acquisition  phase.  This  article  discusses  the 
issues  around  COTS  and  business  process  reengineering, 
and  improvements  we  can  make  to  the  acquisition  process. 
First,  let's  examine  the  reasons  a  COTS  purchase  is  usually 
a  good  choice  by  taking  a  look  at  the  total  cost  of  ownership 
and  configuration  control. 

Total  Cost  of  Ownership  Advantage 

The  total  cost  of  ownership  begins  with  an  estimate  of  all 
direct  and  indirect  costs  that  might  be  associated  with 
the  acquisition  life  cycle.  That  involves  making  some  as¬ 
sumptions  about  the  future  and  then  simulating  various 
scenarios  to  arrive  at  alternative  cost  estimates.  The  goal 
of  calculating  the  total  cost  of  ownership  is  to  support  wise 
decisions  about  all  the  costs  in  the  beginning  and  then 
anticipate  and  manage  those  costs  during  the  life  cycle. 
Changing  to  look  at  software  acquisitions  from  a  tactical 
view  of  the  upfront  and  direct  project  costs  to  a  total  cost  of 
ownership  is  a  significant  paradigm  shift  for  DoD.  The  de¬ 
partment  must  estimate  the  total  cost  of  ownership  against 
its  strategic  objectives— not  from  a  budget  concept.  Many 
of  the  resources  expended  during  a  project  are  internal 
costs,  so  they  are  invisible  in  the  budgeting  process.  The 
total  cost  of  ownership  for  an  unmodified  ERP  application 
versus  a  homegrown  variety  for  a  complex  organization 
such  as  DoD  is  about  45  percent  less  than  developing  cus¬ 
tom  code.  The  greatest  variances  are  in  the  time  spent  to 
upgrade  and  test  the  new  modifications,  and  much  of  this 
is  done  by  the  software  company  in  an  unmodified  ERP 
system  scenario. 

Each  change,  no  matter  how  seemingly  small,  affects 
the  ability  to  test  and  adapt  future  updates  and  software 
changes  efficiently.  Customizations  are  unique  to  the  loca¬ 
tion.  Quite  often,  this  complicates  the  troubleshooting  of  a 
real  bug  in  the  software,  as  it  is  time-consuming  to  separate 
the  real  bug  from  the  custom  code.  There  are  processes 
and  procedures  to  address  such  a  scenario,  but  they  add 
additional  time  and  cost  that  should  be  factored  into  the 
total  cost  of  ownership.  That's  one  reason  why  ERP  sys¬ 
tems  rarely  meet  their  scheduled  delivery  dates  and  never 
meet  their  expected  return-on-investment  objectives. 

The  figure  "Cost  of  Change;  Return  on  Investment"  bal¬ 
ances  the  number  of  features  (software  changes)  against 
the  anticipated  return  of  that  investment.  As  the  number 
of  changes  in  code  increases,  the  increase  is  exponential 
and  quickly  erodes  the  return  on  investment.  The  cost  of 
changing  software  is  not  linear,  but  exponential.  Frederick 
Brooks,  author  of  The  Mythical  Man  Month:  Essays  on  Soft¬ 
ware  Engineering,  attributes  the  exponential  rise  in  costs  of 
software  changes  to  the  cost  of  communication— costs  to 
understand  the  software  to  be  changed,  the  cost  to  under¬ 
stand  what  actually  needs  to  be  changed,  the  cost  to  com¬ 


municate  what  needs  to  be  tested,  the  cost  to  communicate 
what  didn't  work  the  way  it  was  tested,  and  so  on. 

When  the  total  cost  of  ownership  is  considered,  the  cost  of 
a  modified  COTS  can  easily  absorb  any  expected  benefits 
or  return  on  investment.  In  addition  to  the  time  (money) 
spent  in  modifying  the  software,  the  number  of  personnel 
saved  by  applying  consolidated  functionality  via  an  ERP  sim¬ 
ply  translates  into  more  technical  resources  to  maintain  the 
software.  Technical  resources  generally  have  higher  costs 
because  of  the  need  to  analyze,  modify,  and  manage  the 
software  architecture. 

Configuration  and  Change  Control 

The  chief  means  for  controlling  the  total  cost  of  ownership  is 
to  minimize  the  number  and  degree  of  changes  permitted  to 
the  baseline  software.  ERP  packages  are  designed  for  a  large 
audience  of  companies  looking  to  achieve  success  by  follow¬ 
ing  a  template  of  best  business  practices;  however,  software 
often  fails  to  achieve  its  promise  because  of  people's  reluc¬ 
tance  to  change  and  their  adherence  to  old  processes.  That 
leads  to  costly  program  modifications  to  replicate  the  old 
processes.  That,  in  turn,  can  result  in  unnecessary  manual 
tasks  and  software  maintenance  issues,  which  neutralize 
the  original  benefits  of  the  software.  Customization  and 
subsequent  upgrades  are  costly,  and  the  decision  to  hold 
the  line  should  be  made  at  the  beginning  of  the  acquisition 
and  revisited  only  under  the  most  extreme  circumstances. 

According  to  Donald  Burleson  in  his  article  "Selecting  an 
ERP  system:  Build  or  buy?"  (<http://articles.techrepublic. 
com.com/5100-l0878_ll-1040167.html>),  "If  your  orga¬ 
nization  does  not  have  a  clear  competitive  advantage  from 
your  ordinary  business  systems,  an  off-the-shelf  solution 
can  offer  the  greatest  benefit  because  a  packaged  solution 
can  be  used  right  out  of  the  box  and  requires  very  little  IT 
overhead." 


Cost  of  Change:  Return  on  Investment 
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In  a  keynote  address  in  2002  to  the  Third  International  Con¬ 
ference  on  Extreme  Programming,  Jim  Johnson,  chief  execu¬ 
tive  office  of  the  Standish  Group,  quoted  a  DuPont  study 
that  showed  only  25  percent  of  systems  features  were  re¬ 
ally  needed.  “On  average,  45  percent  of  software  features 
are  never  used,  and  only  20  percent  of  features  are  used 
always  or  often,"  he  said,  giving  us  a  frank  reminder  that  we 
need  to  ensure  the  requirement  meets  a  strategic  need  and 
doesn't  simply  pave  an  existing  cowpath  in  the  organiza¬ 
tion's  processes. 

ERP  solutions  are  modular  and  flexible,  and  thus  can  be  cus¬ 
tomized  to  a  certain  degree;  however,  major  modifications 
are  complex  and  extremely  costly.  Software  packages— es¬ 
pecially  ERP  software  packages— have  processes  encoded 
into  their  click  trails  and  transactions  that  will  never  do  ev¬ 
erything  a  customer  wants.  It  is  important  to  remind  the 
integrated  product  team  and  those  who  are  customizing 
software  to  modify  the  COTS  package  only  where  it  is  a 
strategic  advantage.  With  that  in  mind,  DoD  would  make 
very  few  customizations  to  an  ERP  system. 

The  trap  for  program  managers  is  easy  to  fall  into,  though. 
Software  companies,  sponsors,  and  implementation  teams 
are  very  willing  to  justify  customization  at  what  initially 
seems  like  a  very  low  price  to  pay  in  comparison  with  the 
angst  incurred  when  the  program  manager  asks  the  orga¬ 
nization  to  change.  Regardless,  it  is  still  imperative  for  the 
organization  to  change  its  business  processes  to  meet  the 
COTS-embedded  processes  rather  than  customize  the 
COTS  to  meet  the  organization's  process. 

Business  Process  Reengineering 

According  to  a  Feb.  12, 2010,  memorandum  from  the  Office 
of  the  Deputy  Chief  Management  Officer  and  the  Fiscal  Year 
2010  National  Defense  Authorization  Act:  “Section  1072 
does  not  allow  funds  to  be  obligated  for  a  defense  business 
system  modernization  that  will  have  a  total  cost  in  excess 
of  $1,000,000  unless  appropriate  BPR  efforts  have  been 
undertaken.  The  business  process  to  be  supported  by  the 
defense  business  system  modernization  will  be  as  stream¬ 
lined  and  efficient  as  practicable." 

A  memorandum  providing  guidance  on  implementing  the 
2010  National  Defense  Authorization  Act  update  to  U.S. 
Code  222v4,  “Implementation  of  Section  1072  of  the  Fis¬ 
cal  Year  (FY)  2010  National  Defense  Authorization  Act 
(NDAA)-Business  Process  Reengineering  (BPR)  Assertion," 
specifically  states  the  BPR  will  be  done  during  the  require¬ 
ments  generation,  which  for  most  software  development 
and  acquisition  life  cycles  is  before  the  request  for  proposal 
is  released.  Implementing  COTS  business  products,  specifi¬ 
cally  ERPs,  significantly  affects  the  organization's  culture, 
structure,  and  business  processes  in  addition  to  its  proce¬ 
dures  and  rules.  Documenting  business  processes  that  you 
know  will  need  to  be  modified  significantly  in  the  near  future 
is  not  an  effective  use  of  one's  resources.  An  efficient  busi- 


Customization  and 
subsequent  upgrades  are 
costly,  and  the  decision 
to  hold  the  line  should  be 
made  at  the  beginning  of 
the  acquisition  and  revisited 
only  under  the  most  extreme 
circumstances. 


ness  process  is  one  where  the  organization,  process  flow, 
and  the  configuration  of  the  COTS  system  are  done  concur¬ 
rently;  and  you  can't  do  that  until  you  know  what  software 
you  are  purchasing.  V.  Koch's  article,  “BPR  and  ERP:  realizing 
a  vision  of  process  with  IT,"  published  in  a  2001  edition  of 
the  Journal  of  Computing  and  Information  Technology,  further 
pressed  the  need  to  combine  ERP  implementations  with 
BPR: 

The  implementation  delays  and  ERP  product  modifica¬ 
tions  could  result  in  exponential  growth  in  both  direct 
and  indirect  costs. ...  It  would  always  be  better  to  com¬ 
plete  the  BPR  project  prior  to  information  system  mod¬ 
eling  and  ERP  system  development.  Since  the  imple¬ 
mentation  of  large  information  systems  is  not  possible 
without  first  altering  business  processes,  reengineering 
is  essential  in  order  to  extract  maximum  benefit  out  of 
the  ERP  products.  However,  analysis  of  business  prac¬ 
tices  shows  a  different  approach.  Initiating  BPR  projects 
prior  to  ERP  means  that  the  companies  must  provide 
resources  for  two  successive  projects.  The  reason  why 
many  companies  chose  to  conduct  ERP  system  devel¬ 
opment  was  to  attempt  to  solve  all  their  organizational 
problems  without  reengineering  business  processes 
first.  ERP  applications  integrate  many  best  business 
practices  and  much  knowledge  that  could  be  worth¬ 
while  if  included  as  a  part  of  BPR  projects.  By  taking  the 
best  practices  inherent  in  ERP  applications,  companies 
can  change  their  processes  simultaneously  with  tech¬ 
nological  change.  As  a  result,  many  companies  changed 
their  business  processes  to  fit  the  ERP  system  require¬ 
ments,  and  the  possibilities  of  ERP  systems  have  been 
used  to  underpin  BPR. 

Koch  and  the  National  Defense  Authorization  Act  are  accu¬ 
rate  in  stipulating  BPR,  but  it  should  only  occur  in  conjunction 
with  the  COTS  implementation  and  not  before  it.  If  BPR  is 
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not  approached  in  this  manner,  the  new  business  processes 
will  require  rework  and  will  erode  the  cost  benefits  expected 
from  the  initial  BPR. 

Fine-Tuning  the  Program  Strategy 

Executive  leadership  must  be  visibly  involved  in  executing 
strategy,  and  software  implementation  is  no  exception.  Only 
leadership  can  quickly  address  the  disagreements  that  arise 
in  the  process  of  transforming  through  BPR  and  an  ERP  imple¬ 
mentation. 

Rules  need  to  be  modified  to  take  advantage  of  the  evolu¬ 
tionary  strategy  an  integrated  BPR  and  COTS  implementation 
requires.  While  it  is  very  difficult  for  an  integrated  product 
team  of  subject  matter  experts  familiar  with  their  own  pro¬ 
cesses  to  remain  disassociated  enough  to  effectively  deter¬ 
mine  what  needs  to  be  changed,  organizations  can  establish 
rules  to  evaluate  each  change  to  ensure  it  meets  a  strategic 
or  competitive  need. 


processes  while  implementing  enterprise  solutions.  Its  soft¬ 
ware  engineering  waterfall-esque  approach  to  enterprise 
software  acquisition  needs  to  include  the  tasks  related  to  as¬ 
sessing  the  organization  and  adapting  the  organization  to  the 
inherent  software  processes.  Nor  does  the  Defense  Acquisition 
Guidebook  address  the  need  for  business  process  reengineer¬ 
ing  in  parallel  with  COTS  implementation. 

Once  implemented,  the  value  of  ERP  initiatives  becomes 
embedded  in  processes  that  are  difficult  to  quantify.  COTS 
business  software  has  embedded  processes;  therefore,  if 
we  do  business  process  reengineering  before  purchasing 
software,  we  will  have  to  redesign  those  processes  to  the 
ones  inherent  in  the  software  functionality,  and  that  can 
easily  negate  any  gains  resulting  from  reengineering  or 
a  COTS  purchase.  Merging  BPR  with  agile  principles  of 
an  iterative  delivery  and  a  trained  team  of  technical  and 
business  experts  will  result  in  a  program  that  is  truly  per¬ 
formance-  and  results-based. 


ERP  systems  and  implementation  teams  are  experienced  in 
delivering  software  all  at  once  versus  an  incremental  deliv¬ 
ery;  however,  BPR  and  ERP  can  be  delivered  incrementally, 
prioritizing  process  and  technical  improvements  by  need, 
value,  or  other  criteria.  Such 
agile  principles  applied  to  an 
integrated  BPR  and  ERP  yield 
significant  and  early  results. 

So  while  we  can  decrease 
our  long-term  sustainment 
costs  through  the  use  of 
COTS  purchases,  we  can  do 
so  only  if  we  modify  our  pro¬ 
cesses  to  match  those  inher¬ 
ent  in  the  software  system. 

If  we  intend  to  do  our  part 
to  decrease  the  deficient, 
our  acquisition  strategy  and 
program  management  plan 
must  incorporate  that  ap¬ 
proach  from  initiation  to  bet¬ 
ter  prepare  the  end  users  for 
the  paradigm  shift  they  will 
encounter.  Furthermore,  we 
need  to  market  organiza¬ 
tional  change  for  the  posi¬ 
tive  it  is— the  embracing  of 
the  software's  processes  and 
the  resultant  significant  sav¬ 
ing  in  sustainment  costs.  To  do  so,  we  need  to  close  the  gaps 
in  our  acquisition  skill  sets— specifically  our  skills  in  process 
engineering. 

Incorporate  DFSS  into  the  Guidebook 

The  Defense  Acquisition  University  Defense  Acquisition  Guide¬ 
book  does  not  currently  address  the  need  to  modify  business 


Bring  in  Lean 

In  his  book  Design  for  Six  Sigma,  Subir  Chowdhury  states 
that  changing  a  design  after  a  product  launch  and  not 
during  the  development  state  can  cost  a  company  a 

thousand  times  more.  Ex¬ 
tending  this  understand¬ 
ing  that  systems  design  in¬ 
cludes  human  factors  and 
processes,  it  is  clear  that 
our  teams  need  the  neces¬ 
sary  skills  to  design  these 
processes  in  their  BPR  ef¬ 
forts  and  major  defense 
acquisition  programs  to  be 
effective.  One  of  the  op¬ 
tional  continuing  education 
courses  offered  by  DAU  is 
Lean  Manufacturing  (CLB 
007).  The  course  touches 
on  Six  Sigma  and  provides 
familiarity  with  the  terms. 
For  more  in-depth  training, 
DoD  has  adopted  Lean  Six 
Sigma  green  and  black  belt 
certification  programs.  We 
need  to  add  Lean  Six  Sigma 
certification  to  the  current 
Defense  Acquisition  Work¬ 
force  Improvement  Act 
certifications  for  informa¬ 
tion  technology  and  program  management. 

DoD  50000.01  requires  acquisition  teams  to  adopt  inno¬ 
vative  practices  to  reduce  time,  assuming  that  the  teams 
have  the  skill  sets  in  process  improvement  and  transfor¬ 
mation.  It  also  drives  program  managers  to  reduce  tech¬ 
nology  risk  and  states  that  the  “acquisition  of  software 


We  need  to  add  Lean  Six 
Sigma  certification  to  the 
current  Defense  Acquisition 
Workforce  Improvement 
Act  certifications  for 
information  technology  and 
program  management. 
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intensive  systems  shall  use  process  improvement  and  per¬ 
formance  measures."  But  how  many  program  managers 
and  integrated  product  teams  have  the  skills  to  frame  their 
programs  to  maximize  the  benefits  of  adopting  iterative 
delivery  practices  and  process  reengineering? 

Sponsors,  program  managers,  and  the  integrated  product 
team  members  must  be  able  to  assess  the  technological 
and  business  process  issues  involved  with  specific  ERP 
applications.  It  must  be  stressed  that  failing  to  match 
business  processes  with  a  company's  ERP  system  can 
derail  even  the  best-run  organizations.  Managers  and 
employees  must  be  able  to  assess  the  technological  and 
business  process  issues  involved  with  specific  ERP  ap¬ 
plications. 

The  military  services'  Lean  Six  Sigma  initiatives  are  per¬ 
fectly  aligned  to  be  merged  with  our  acquisition  frame¬ 
work,  with  a  few  subtle  tweaks.  These  initiatives  embrace 
the  classic  DMAIC  process— or  define,  measure,  analyze, 
implement,  and  control  phases— typically  applied  to  con¬ 
tinuous  improvement.  This  view  attacks  root  causes  of 
existing  processes.  Design  for  Six  Sigma  (DESS)  attacks 
a  company's  problems  during  the  product  and  process 
development  state.  While  the  tools  and  order  used  in 
Six  Sigma  require  a  process  to  be  in  place  and  function¬ 
ing,  DFSS  has  the  objective  of  determining  the  needs  of 
customers  and  business,  and  driving  those  needs  into 
the  product  solution  so  created.  DFSS  is  relevant  to  the 
complex  system/product  development  phase,  especially 
in  the  context  of  a  new  system.  It  is  process  generation 
in  contrast  with  process  improvement.  DFSS  strives  to 
generate  a  new  process  where  none  existed  or  where  an 
existing  process  is  deemed  to  be  inadequate  and  in  need  of 
replacement.  DFSS  aims  to  create  a  process  with  the  end 
in  mind  of  optimally  building  the  efficiencies  of  Six  Sigma 
methodology  into  the  process  before  implementation;  tra¬ 
ditional  Six  Sigma  seeks  for  continuous  improvement  after 
a  process  already  exists. 

In  conclusion,  DoD  5000.01  and  the  Fiscal  Year  2010 
National  Defense  Authorization  Act  require  process  im¬ 
provement  and  performance  measures  in  concert  with 
industry  best  practices,  but  stop  short  of  delivering  the 
value  envisioned  as  they  require  business  processes  to 
be  reengineered  prior  to  the  selection  and  purchase  of 
a  COTS  business  solution.  The  COTS  technical  solution 
will  have  built-in  processes  that  will  be  expensive  if  not 
impossible  to  change.  We  must  build  business  processes 
around  the  capabilities  of  the  technology  and  not  modify 
the  technology.  We  must  also  train  our  program  managers 
in  Lean  Six  Sigma  practices  so  they  can  effectively  lead  the 
team  to  achieve  the  most  efficient  and  effective  balance 
to  execute  our  agency  of  tax  payer  dollars. 


Program  Managers 

e-TOOL  KIT 

https://pmtoolkit.dau.mil/ 

The  Program  Managers  e-Tool  Kit  provides 
the  program  management  resources  of  the 
popular  print  Program  Managers  Tool  Kit  in 
a  dynamic  Web-based  format  It  covers 
acquisition  management  across  all  functional 
areas  and  provides  leadership  and  problem¬ 
solving  tools. 

The  e-Tool  Kit  features: 

✓  Continual  content  updates 

✓  Live  policy  links 

•/  Links  to  informative  ACQuipedia  articles  ^ 
and  related  communities  of  practice  ^ 


The  author  welcomes  comments  and  questions  and  can  be 
contacted  at  cindy.shelton.l(a)us. af.mil. 
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